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(54) Title: SECURE MESSAGING TABLE SYSTEM 

(57) Abstract 

The present invention relates to secure 
messaging using a telecommunications net- 
work or the like, particularly but not ex- 
clusively in environments where the mes- 
sage is intended to be carried over an un- 
secured telecommunications link. Without 
limitation, one application of the present in- 
vention is in financial transactions between 
a customer, vendor and financial institution. 
In essence, ihe present invention stems from 
the realisation that by providing second iden- 
tifiers in association with the first identifiers, 
it is possible to determine whether transac- 
tions are valid or invalid. 
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SECURE MESSAGING TABLE SYSTEM 
Technical Field 

The present invention relates to secure messaging using a 
telecommunications network or the like, particularly but not exclusively in 
5 environments where the message is intended to be carried over an unsecured 
telecommunications link. Without limitation, one application of the present 
invention is in financial transactions between a customer, vendor and financial 
institution. 
Background Art 

10 Electronic messaging systems of various types have come into increasing 

use over the last decade. Such developments as widespread use of internal 
networks, and the increase of internet access and use, have contributed to this 
growth. 

Secure messaging is traditionally carried out using one of several 
15 mechanisms. In one type of arrangement, exemplified by electroric funds 
transfer all terminals are uniquely identified, the lines are insecure, and session 
keys are generated for each transaction using real time on-line links between 
the terminal and the host. However, such a system is not suitable where 
messages may be received out of order, as in a packet based system, or where 
20 communications real-time links may be unreliable. 

Another alternative is the use of asymmetric key encryption, such as RSA, 
in which a public key is disseminated, with the private key held only by the 
intended receiving party. A corresponding relationship needs to be established 
" to allow for two-way communications. In such systems, the same key is used for 
25 numerous transactions, which creates a security risk over time - in other words, 
the key is not unique to any given communication. 

It is an object of the present invention to provide a secure messaging 
system which allows for secure message transfer and verification, but where 
there is no real time link between the sender and the receiver, and messages or 
30 transaction data may be received out of order. 
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Summary of the Invention 

According to a first aspect, the present invention comprises a system for 
securely communicating Q message from a transmitting means to a receiving 
means, said transmitting means having a first unique identifier, said message 
5 including a second identifier generated by said transmitting means which is 
unique for each message, wherein said transmitting means encrypts said 
message, and generates a message block including said encrypted message 
and said first identifier in unencrypted form, said message block being 
transmitted, wherein said receiving means is enabled to decrypt the message 
10 us.ng the first unique identifier, and includes a list of possible second identifiers 
for the transmitting means associated with the first identifier, and an indication of 
whether such second identifiers have been used, so that said message block ,s 
recognised as valid only if the second identifier associated with the message 
block has not previously been used. 

1 5 In essence, the present invention stems from the realisation that by 

prov.d,ng second identifiers in association with the first identifiers, it is possible 
to determine whether transactions are valid or invalid. 

Preferably, the encryption is performed using an encryption engine 
conta.ned within a secure hardware element of the transmitting means For 
20 example, the transmitting means may comprise a secure smartcard reader in 
combination with the customer's smartcard, and a PC or similar device 
connected to a modem. Preferably, the encryption engine generates a unique 
key for each transaction, by operating a suitable function on one or more 
random or pseudo-random numbers generated by the transmitting means This 
25 random number is in this case transmitted un-encrypted in the message block to 
the receiving means. The receiving means stores decryption information 
associated with the transmitting means, so that given the first unique identifier 
and the random number, the message can be decrypted. This provides a 
unique key for each message without the necessity for a real time Unk 
30 However, the present invention may be implemented using an RSA or similar 
system, with the message identifier providing security to ensure that the 
message did originate from the transmitting means. 
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The present invention is particularly applicable to systems such as the 
internet, and more particularly to arrangements in which a secure transaction 
may pass through several parties before being presented to the intended 
recipient. An example of such an application is a payment instruction from a 
5 party to purchase goods via the internet. The fundamental relationship to effect 
the payment is between the customer and the financial institution which will pay 
the vendor. Hence, the customer may send a message block to the vendor, 
including unencrypted data such as the amount, the customer's financial 
institution, and the date, together with an encrypted confirmation of these details 

10 and confidential details such as a credit or debit card number, a PIN ( personal 
identification number), transaction value and the customer's account details. 
The vendor may pass the message block to his bank, for later submission to the 
customer's bank. Alternatively, if the transaction has a small value, the vendor 
may store the message blocks and submit them as a batch to a bank or financial 

15 institution. In either case, the unique (second) identifier associated with each 
message allows the customer's bank to determine whether the transaction is 
legitimate or fraudulent. Certainly, any simple cloning of the message block will 
not succeed, as the clone will have the same message (second) identifier and 
hence be refused by the customer's bank. 

20 Alternatively, the cloned message will be accepted by the customers 

financial institution in the event that it arrives at the financial institution before the 
genuine or delayed original message. The genuine delayed message may then 
be rejected on its arrival. However, the cloned message can only have 
achieved the same objective as the genuine message should have done, 

25 unless it was otherwise tampered. In the event it was tampered, the message 
decryption will fail and the allocated transaction number will not be recovered 
from the decryption. Thus if the clone message is tampered, it will fail. The 
genuine message will eventuate. 

Other applications of the inventive system will be apparent to the reader. 

30 Thus, the present invention provides a messaging system which allows 

for secure messages to be transmitted without any acknowledgment to the 
sender. 



WO 98/32260 



PCT/AU97/00888 



Brief Description of the Drawings 

One illustrative embodiment of the present invention will now be 
described with reference to the accompanying figures, in which: 
Figure 1 is a schematic overview of a general arrangement in which the present 
5 invention may be used; 

Figure 2 is a block diagram illustrating one possible encryption process in the 
transmitting device; 

Figure 3 is an example transaction certificate format; 
Figure 4 is an example of a block message format; and 
10 Figure 5 illustrates an exemplary algorithm for generating a transaction key. 
Detailed Description 

The present invention will be described with reference to a particular 
application, that of funds transfer over a communications network such as the 
internet. However, it will be understood that with suitable modifications the 
15 present invention is more broadly applicable. The design and details of the 
encryption system, and receiver and transmitter elements, are not essential in 
detail to the present invention - i, is onlv their functionality which defines the 
present .nvention. Greater or .esser .eve.s of encryption security may be used 
depending upon the wishes of the system implementer. 
20 Referring to figure 1, the arrangement shown is one in which a domestic 

customer wishes to purchase goods or services from a cyber merchant - i e one 
accessible via the internet. The home user has a magnetic stripe or smartcard 
cred,t or debit card, a secure device card reader, and a PC and modem 
connected conventionally for internet access. Security functionality may be 
25 shared between a smart card and/or a card reader dependent on the capabiiity 
of each ,tem. The other parties shown are the merchant, which is the vendor 
the acquirer, which is the financial institution with whom the merchant has a 
relat.onship; the card issuer, who has a relationship with the customer; and the 
device issuer, who supplied the secure device card reader It will be 
30 appreciated that less complicated arrangements are possible where, for 
example, the device issuer is the card issuer, or the merchant and customer 
share the same financial institution. 
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A typical debit purchase transaction may operate as follows: 

1. Customer selects item(s) for home purchase from the merchant's web 
site, and initiates purchase software between the merchant's site and the home 
PC. An applicable software "shopping" application exists, with hooks to import 

5 and export data to a Secure Device attached to, for example COM2. The import 
/ export control between the application and the Secure Device will be a 
separate control protocol. 

2. Customer has a mag stripe, linked or smartcard debit card. 

3. Merchant provides purchase details - for example, merchant ID. value of 
10 transaction, and other relevant data. The merchant ID is transported securely 

(eg SSL) between the merchant's web site and the customer, for inclusion in the 
purchase certificate (TC1) and inclusion of the Merchant ID in the secure 
component of the customer message, allows accurate Merchant ID for payment 
etc. 

15 4. Customer purchase software confirms debit and requests card reading / 
swipe. The secure device checks for correct reading of the card. 

5. Customer purchase software initiates "GetPIN" to secure device, which 
encrypts and stores the entered clients PIN. 

6. Secure device encrypts PIN and concatenates result with other 
20 transaction data. An advanced transaction number is assigned - this may be 

simply 1, 2. etc. or selected from a more complex predefined set. Concatenated 
result is cryptographically incorporated into a transaction certificate using a 
second encryption process. An illustrative transaction certificate is shown in 
figure 3. This encryption may be. for example, using the public key of an 

25 asymmetrical key pair, issued by the device issuer. The secure device is 
capable of PIN encryption with symmetric double length keys and is capable of 
encrypting multiple data blocks with a stored protected asymmetric 1024 bit 
modulus Secure Device Issuer public key half. 

Alternatively, the asymmetric public key component may be replaced with 

30 a symmetric key derivative of the base key and the random number. 

7. Assembled purchase transaction is sent to the merchant, e.g. via email or 
Internet, see Figure 3 & 4. 
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8. The transaction may be stored by the merchant for batching into a set of 
transactions for upload to the acquirer institution. A transaction transfer protocol 
is designed or exists to satisfy these requirements. 

Note: The Merchant may or may not have issued the customer Secure Device 
5 reader and / or the customer mag stripe card. In this scenario, it is assumed that 
the Acquirer has issued neither. Thus, where the Merchant has issued one or 
both the reader or card, simplification of these steps is possible. 

9. The acquirer determines, from for example unencrypted information in the 
message block, which institution issued the secure device sourcing the 

10 transaction. The transaction message provides a Secure Device identifier to be 
contained within external plain text data, as well as within the certificate. 

10. The transaction is forwarded to the secure device issuer, for certificate 
data recovery, using existing (INTERCHANGE) interbank secure communication 
systems. 

15 11. The secure device issuer decrypts the certificate data and checks the 
transaction number against a transaction number database indicating the 
possible transaction numbers for the device, and which of those transaction 
numbers have been used. If the transaction number has been used, the device 
issuer will send a message indicating an error or duplication to the acquiring 

20 institution. The entire recovered transaction is now sent to the acquirer, for 
normal processing and exchange with the issuing institution. The acquirer will 
then advise the merchant whether funds are cleared or not. The secure device 
issuer can verify the transaction certificate and check for device transaction 
duplication (replay) in the transaction number database. The checking 

25 application will record the current transaction in the database so it too cannot be 
duplicated. The transaction will be recovered in an Issuing Institution Security 
Control Module (card no. t $vaL..etc). 

12. The process proceeds as an existing interchange transaction, via the 
Acquirer. The secure device issuer can return (interchange) the reconstructed 
30 message data to the Acquirer for standard interchange processing. 
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13. The merchant is informed if the funds are to be forwarded or not. A funds 
failure mechanism exists to provide the merchant with payment "OK" or 
"Rejected". 

It will be appreciated that many of the elements of the system are already 
5 in use, and hence will not be explained further in detail. For example, interbank 
communications may proceed as normal - the only change is the requirement 
for involvement by the device issuer. Purchase software is already widely 
utilised for internet shopping - the only modification required is to ensure 
adequate security and controls between the software and the secure device. 

10 Similarly, the secure device may be merely a simplified version of the card 
readers currently used for POS transactions. 

A key feature of the present invention is that the secure message is 
assembled by the customer, not the merchant, with a unique identifier for the 
secure device and for the transaction, as well as the usual PIN inserted by the 

15 customer. The probity of intermediaries is not crucial to a secure transaction 
occurring. The present invention enables the device issuer to identify the 
source of the message, and verify that replay or duplication of the transaction 
has not occurred, without any direct communication between the secure device 
and the issuer. Moreover, no acknowledgment needs to be sent to . the issuer's 

20 customer, other than a normal statement entry in due course. Even if 
transactions occur out of order, for example transaction 15 is received by the 
issuer after transaction 16. the transaction can still proceed and be confirmed as 
valid - this is not possible with conventional POS systems. 

The transaction described above relates to debit transactions - however, 

25 it could be applied to credit transactions, or to any other process where it is 
essential to confirm that the data originated from the correct source, as well as 
keep the data itself secure, but real time connection is not always possible. 
Examples include medical and insurance data, confidential reporting and 
negotiable security instructions. 

30 The present invention fully supports current standards fcr the interchange 

of financial institution data, and provides a complete audit trail. 
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The merchant data is preferably sent to the customer using appropriate 
encryption established between the merchant and the customer. 

There are two relevant forms of encryption. They are Symmetric & 
Asymmetric respectively. 
5 Symmetric Keys - General 

Symmetric encryption uses a common shared key between two parties. 
The DES algorithm (Data Encryption Standard - DEA1). has been the 
accepted means of symmetric encryption, within the Financial Industry. 

DES has traditionally used Single Length (8 byte / 64 bit) keys, of whicJ- 
10 56 bits are actuall/ used in the encryotion process. Because of increases ir 
attacking computer power, single length keys must be extended to double 
length, using a modified encryption, process. The double length key is split inic 
components called Key Left and Key Right. 

A double length key is denoted by an asterisk, e.g. *KM 1 This example 
1 5 shows Double length Masterkey number one). 
Secure Device Encryption Process 

Referring to Figure 2. the top two boxes of this diagram snow the device 
master key. It is a 'Master Key. The key is loaded into secure device storage 
and cannot be recovered or read back outside the device. 
20 PIN Encryption Process for UATEKS 

The device 'Master Key. (*KM) is loaded by the Secure Device ISSUER, 
e.g. in this case, the CBA. When required to encrypt an entered PIN. the key is 
passed through a non linear modification algorithm, seeded by random value 
(R1). 

25- The resultant derived 'Session Key encrypts the PIN. 

C1 = 'e(PIN) = , n (R1/KM). 

The encrypted double length result. C1. together with the random seed. (R1). 
are stored in the Transaction Certificate generator. 
Device Transaction Tracking Process 
30 Each Secure Device will produce a sequentially incremented device 

transaction number (T1). The device transaction number size will be of sufficient 
length to allow a reasonable time span of events to be recorded for reolav 
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check.ng and velocity checking at the host databases. The counter , s never 
reset and on.y advances in value. At the end of .ts cycle l.fe. sufficient t.m e will 
have elapsed for the host database to recognise that roll-over to . for example 
00000000 is a reasonable event span for that particular dev.ce. 
5 Each transaction value of (T1 ) is placed .n the Certificate Generator 

Magnetic Swipe Track 2 Data 

Any transaction will require the user to sw.pe a card for Track 2 data to be 
captured. Track 2 data might also be obtained from a smart card file. 

Track 2 contains all pert.nent data to determ.ne account detail* |, ,<; 
10 protected by placing the entire rack 2 data w.th.n the Transaction Cert.fcate 
generator. 

Transaction Certificate Generator 

Asymmetric Keys 

The secure Dev.ce w.li use an asymmetnc kev half. ( PK y which mav be 
1 d termed the PUBLIC key component. 

I" reality, th.s key component need no: be oub-.c and can ce store- -r. 
oev.ce secure storage, along w,r the device master kgv 

The transact.cn certificate generator ,s an ' asv mr, e tr,- enrr V ~. 0 r 
algorithm w.th.n the card reader dev.ce The asymmeinc kev half ."PK- u*ed ,~ 
20 produce the certificate ,s treated, .n the dev.ce. as a secure genenc key. m:oue 
to the Secure Device Issuer. 

Note 1: Each Secure Dev.ce could have -ts own un-aus asynm«tr,c 
key set. However, this .s a waste of resources when the "Publ.c" half of the kev 
can be protected in the same way that the unique device 'Master Kev .s stored 
25 Th, s removes the need for "PKV certification. Device unique keys would also 
require additional Issuer host storage space. 

Note 2: Alternatively each Secure Dev.ce PK1 could be delivered 
from the reader dev.ce. to an associated terminal PC. together with the 
assembled content of the generator f Figure 3 illustrates an example TCi 
30 Format). Th.s might perm.t faster transaction certificate assembly. It would also 
support a case for a device unique PKl However, th.s .s not a prefe- -d 
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method and would greatly reduce the security of the transaction, potentially 
allowing fund values and Merchant ID etc to be altered. 

Note 3: If an asymmetric PK1 is impractical, it is possible to use a 
symmetric derivative variant of the base key. to produce a signing key in lieu of 
5 PK1 . 

The transaction certificate. TC1. can only be recovered by the Secure 
Device Issuer. Thus. ALL transactions must come through the device Issuer, 
before the transaction can be piaced into conventional Interchange, for 
processing. 

10 This would allow selling transactions back to other card issuers. '■ the 

Secure Device issuer were no: the Card Issuer as weH 

Figure ~ illustrates an example of both a symmetric and asymmetric bloc* 

message format. 

Secure Reader device 
15 The reader device may be purpose built or may be existing technology. 

The reader can be constructed with a security processor chip capable c' 

operating to industry standards The encryption processing can be capable of 

both DES and asvmmetnc operation Preferably, tre asymmetric key length 

moduli is 1024 bits A fixed timing block of output of re. wits mav be p-ov.de.: 
20 Device power con'-o' migrv. be actuated by e.g. DSR RT5 etc on PC w:tn inbuilt 

power drop delays etc 

Key Rotation Algorithm 
Referring to Figure 5. 

Base Key KM: (Reference numeral 1) Consists of a device unique Key. 12S 
25 bits long. This key is programmed by the Issuer, into each device and also 

stored in the Issuer OCRF database, protected by a domain master kev. 

(Conventional process). The key is recalled for each PIN decryption process, tc 

derive the session key(s) for the current transaction. 

Random Generator R1(L) & R1(R): (Reference numeral 2) The combined 
30 random components R1(L) and R1(R) are each a minimum of 64 bits long the 
combined 16 byte resultant value is transmitted in the plain text message sent to 
the Issuer. 
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Hash Function (#Fn): meferenca numeral 3- Eacr has function ,s identica; 
The 128 bit dev.ce key B1 .s hashed to 64 bus using the left and right Ri and Rz 
components respectively. Fach 64 bit product is denoted »1L and'*2R .n F.gurl 
5 schemat.c. Each 64 bit hash product is ther concatenated to oroduce the final 
5 128 bit session key S1 (reference numeral 4) requ.red by the encrypt function :c 
produce C1 (IPIN) in Figure 2. 

Hash.ng Functions are well known to those skilled in the art. The choser 
hashing algorithm should be cryptograph.cally robust and may be drawing from, 
but are not confined to. e.g. SHA or the MD series. 
10 Encrypnon algontnms are not conf.ned to those cescr.bed. bu: shou.T 

any case, Pa robust and f,t for purpose. DES. Triple DES or IDEA are examoie* 
applicable to symmetric encryption whereas RSA. LUC or ell.pt-c curve ar - 
exPmples applicable to asymmetry function requirements. 
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THE CLAIMS DFFIN'INft THp IMVpM T lQN ARRAS FOI J OWS 

' A system for relatively securely communicating a message from a 
•transmiiting means to a receiving means, said transmitting means having a firs: 
unique identifier. sa;d message including a second identifier generated by said 
transmitting means which is unique for each message, wherein said transmitting 
means encrypts said message, and generates a message blccK including said 
encrypted message and said first identifier in unencrypted form, said message 
block being transmuted, wherein said receiving means is enabled to decryc: the 
message using the first unique identifier, and eludes a lis: of Possible second 
identifiers for the transmitting means associated with the first identifier, and ar 
indication of whether such second identifiers have been used, sc that 
message block is recognised as valid only if the second identifier assocatec 
with the message block has not previously been used. 

2. A system as claimed in claim 1. wherein the encryption is oerformec 
i;s ig an encrypt.on engine contained within a secire hardware element o' tne 
transmitting means. 

3. A system as claimed in claim 1 0 r 2. wherein ;ne encrypts engine 
generates a unique key for each transaction. 

4. A system as claimed in claim 3. wherein a second number is transmitted 
un-encrypted in the message block to the receiving means 

5. A system as claimed in claim 4. wherein the receiving means stores 
decryption information associated with the transmitting means, so that given the 
first unique identifier and the second number, the message can be decrypted. 

6. A system as claimed in claim 4 or 5. wherein the second number 
associated with each message allows determination as to whether the 
transaction is legitimate or fraudulent. 
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7. A method of determining whether a financial transaction is to be 
approved or rejected in a system of electronic transaction services, the method 
including the steps of: 

checking a transaction number against a transaction number database 
indicating the possible transaction numbers for a device, the database also 
indicating which of those transaction numbers have been used, and 

if the transaction number has been used, sending a message indicating 
the transaction is rejected. 

8. A method as claimed in claim 7, further including the step of: 

determining, from the electronic transaction data which party issued the 
device sourcing the transaction. 



9. 



A system method or device as herein described. 



WO 98/32260 



PCT/AU97/00888 



1/4 




WO 98/32260 



PCT/AU97/00888 



2/4 






9 




8 lit 


*-» 

c 




co 






si 




Ol iS 

CL 03 


o 

t_ 




0) 




< Q 


£ 

CD 




JC Q. 






6 ^ 


03 




> 





cn 




c 




1*: 
i— 




o 


CD 








on 






c 


o 




sa 


0) 


c 


XI 


Tra 


ID 


o 




Q 





tion 


iter 




o 






CO 


o 




to 
c 


O 


o 


CO 


15 


rati 


o 


c 


CD 


CD 


C 




Z3 


CD 


"> 

Q) 


cr 

CD 




Q 


CO 





(N 

P-l 





CO 


ipe 


3 
CL 






C 




CO 





.9 
**— 

a> 

E 

E 

CO 

< 

o3 



>^ 

CD 

-3 CO 
CD 

O 



c 
o 

13 
k_ 

CD 
C 
CD 
CD 



CO 
CD 

o O 

CL H 




"F 



0) 

E 

E 
>, 

CO _ _ 

<C \o 
.2 .9 O 

~ 'ZZ o 
c o 

CD CO 
CO 

c 

OS 



CO 

.£= 
"eg 

c 

CO 

c 



CD 
O 

Q 

CD 



a 

CD 

CO 




WO 98/32260 



3/4 



PCT/AU97/00888 



=3 



0^ 



O 

c 

CX3 



(L) 
O 

> 

Q 



c 

<o 
O 

-a 

c 

OS 



o 



> 



5 ^ 
ft fc> 



a. 




W ° 98/322<1<l PCT/AU97/00888 



4/4 



Fig 5. 
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